「クラウドシフトにあわせたAWSセキュリティ強化のはじめ方」というタイトルで登壇しました

こんにちは、臼田です。

みなさん、たのしいセキュリティやってますか？(挨拶

今回は8/6（木）に開催した「クラウドシフトにあわせたAWSセキュリティ強化のはじめ方」での登壇資料を共有しその解説を行います。

動画(2020/08/19追加)

資料

解説(2020/08/19追加)

前説

• セキュリティ対策って大変ですよね
  • AWSセキュリティのどこが不安ですか？
  • いろんな段階があるので、段階(クラウドジャーニー)に基づいた対策をしていきましょう
  • 判断するのはCCoEなどの組織が中心であるといいです
  • クラウドジャーニーの参考資料
    • 資料: https://pages.awscloud.com/rs/112-TZM-766/images/H-01.pdf
    • 動画: https://www.youtube.com/watch?v=Sc9hBNHGHcE
  • 6つの観点と4つのステージや展開のための3つの打ち手が紹介されている
• セッションの目的
  • いろんな段階の人にAWSセキュリティの全体像を伝えて 少しでもたくさん持って帰ってもらう
    • -> 実践してもらう
  • 実践するためには? -> 1人では頑張れない!
  • この資料を展開して周りを巻き込んでください!
• 持ち帰ってほしいこと
  • クラウドは武器、ビジネスを加速させる
  • クラウドセキュリティも武器
  • アジリティを落とさない攻めのセキュリティ
  • ゲートからガードレールへ
    • セキュリティはビジネスにブレーキをかけてはいけない
    • ガードレールのように道から逸れないように危ない操作を出 来ないようにしたりすぐ是正できるよう監視/自動修復する
    • とりあえず一括で禁止しない

アジェンダ

• 1. AWSのセキュリティと全体像
• 2. AWSセキュリティの実践

もし「そもそもAWS自体 のセキュリティが心配(と 偉い人が言っている)」と いう段階の場合は下記を参照

1. AWSのセキュリティと全体像

• 目次
  • 1. 1. AWSセキュリティの考え方
  • 1. 2. AWSセキュリティの全体像
  • 1. 3. 最初のアプローチ

1. 1. AWSセキュリティの考え方

• セキュリティの前にそもそもAWSのメリットとは?
  • AWS の クラウドが選ばれる 10 の理由
    • いくつか抜粋
    • 初期費用ゼロ/低価格
    • 
    • 柔軟性
    • 
    • 俊敏性
    • 
    • マネージドサービスによる運用負荷の軽減
    • 高いセキュリティを確保できるのもメリット
    • 
    • 高いセキュリティを確保できるのもメリット
    • 
  • メリットはいろいろある
    • 全てはビジネスを加速するためにある
    • セキュリティもビジネスを加速させるためにある
    • セキュリティがそれを妨害してはならない
    • AWSでは特に他の要素とトレードオフせずにセキュ リティを強化できる -> 攻めのセキュリティ
    • 目的は一緒なら手を取り合い進められる
• AWSセキュリティの前提 -
• 責任共有モデル
  • 
  • 守るべき部分は明確
• 参考にするドキュメントいろいろ
  • NIST サイバーセキュリティフレームワーク(CSF)
    • 世界各地の政府、産業界、組織において参照されているサイバーセキュリティの推奨ベースライン
    • 日本でもIPAのホームページから邦訳版を入手可能
    • コア機能は5つ
      • 識別 / 防御 / 検知 / 対応 / 復旧
      • AWSでのCSF対応表など
  • AWSセキュリティベストプラクティス
  • Well-Architectedフレームワーク
    • AWSのベストプラクティス集
    • 5 つの柱がある(運用上の優秀性、セキュリティ、信頼性、ハパフォーマンス効率、コスト最適化)
    • セキュリティの柱の中にも6つのベストプラクティス
      • セキュリティ
      • Identity and Access Management
      • 検出
      • インフラストラクチャ保護
      • データ保護
      • インシデント対応
    • Well-Architectedフレーム ワークが2020/07/10に更新された
    • [アップデート] AWS Well-Architected フレームワークおよび AWS Well-Architected ツールが更新されたので、どこが変わったのかを調べてみた
  • PCI/FISC/HIPPA等各種コンプライアンスのドキュメント

1. 2. AWSセキュリティの全体像

• ざっくりと2つに分けられる

• もう少し詳細に

• 全体像に対する参考情報

• 全体像の捉え方とブレークダウンの仕方
  • 単体システムのセキュリティから取り組むといい
    • PoCやモード2のシステムなどスモールであったり始めやすいものから覚えていく
    • 組織的なセキュリティを考えようとしても具体的なAWSへの理解と活用が必要となるため
  • 習熟してきたらそのメンバーを中心に全体を考える
  • 参考資料は最初からずっと役に立つ
    • 常に最新のものをインプットして適材適所で活用

1. 3. 最初のアプローチ

• まずはAWSを知る
  • 最初はトレーニングがオススメ
  • 無料のEラーニングもいっぱい
  • スタートダッシュするなら公式トレーニングも活用
  • セキュリティのコースとラーニングパスもある

• AWSの参考情報はいっぱいある
  • 公式ドキュメント、ブログ等
  • JAWS-UG、勉強会、コミュニティ
    • Security-JAWSもあるよ
    • 3ヶ月毎に開催しています

2. AWSセキュリティの実践

2. 1. 単体システムのセキュリティ

だいたいこちらで紹介しましたので割愛。

• 上記からの追加要素
  • Amazon Detectiveがリリースされているので使おう！
    • 解説動画
  • 宣伝: 脆弱性管理運用コンサルティングのサービスをはじめました
    • 自分たちで管理することをやっていきたいという方ご相談ください
  • F5からAWSマーケットプレイスから利用できるSaaS型の高機能WAFがリリースされた
    • WAF運用で楽したい方へおすすめ
  • AWSシステム構築非機能要件ヒアリングシートを公開しています。参考にしてみてください

2. 2. 組織的なセキュリティ

• 2. 2. 1. 組織・仕組みづくり
  • CCoE作る
    • Cloud Center of Excellence (CCoE) 多様な専門知識を持ったチーム
      • 早い段階からクラウドに取り組み、成熟して全体のクラウド活用の支援に回る役割
      • 部署横断でバーチャルな組織にする場合も
      • クラウド全体管理の仕組みやセキュリティチェックリストの作成なども実施する
      • 進め方の例
    • 参考事例
      • 森永乳業株式会社様
      • CCoEによりクラウド活用を推進。複数ツールの組合せでセキュリティを強化
      • クラウドシフトに合わせたセキュリティと運用の見直しなど協力
• 2. 2. 2. ID管理
  • AWSアカウントが増えてきたときのIAM管理は大きく2種類
    • シングルサインオン(SSO)を利用
      • 既存でSSOの仕組みやADなどがある場合
    • AWS SSOというサービスもある
    • IAM管理用AWSアカウントを作成し、SwitchRoleでAWSアカウント切り替え
      • AWSだけで簡単に集中管理できる
  • [AWS Black Belt Online Seminar] AWSアカウント シングルサインオンの設計と運用 資料及び QA 公開
  • IAM集中管理の仕組みを作る方法
• 2. 2. 3. ガードレール
  • AWSのマネジメント & ガバナンスサービスなどを利用することによりガードレールを実現できる
    • AWS Organizations
      • 複数のAWSアカウントをまとめて管理する仕組み
      • SCPにより管理アカウント全体に制限をかける
    • Config Rules
      • ルールから逸脱した設定変更を検知して通知・是正する
  • 詳しくは動画で
    • マネジメント&ガバナンス系のサービスの手厚い解説
    • 動画もあります
    • 具体的な実践方法もあります
  • AWS環境なら監査も進化できる
    • AWS環境はAPIを駆使して監査ができる
    • コンプライアンス要件を冗長で解釈によってブレが大きい文章で定義するのではなく、コードで定義できる
    • より明確なコンプライアンス要件となる
    • Compliance as Code(CaC)と呼ぶ
    • re:Inforce2019で行われたCaCセッション: Your first compliance-as-code - GRC305-R - AWS re:Inforce 2019
• 2. 2. 4. 発見的統制・インシデントレスポンス
  • 発見的統制(Detective Control)
    • 例えばWAFやパッチ適用でインシデントを予防するだけでなく、インシデントが起きた時に気付けるようにしておく
  • インシデントレスポンス(IR)
    • インシデント(障害とかセキュリティ事故とか顕在化した脅威など)の対応(レスポンス)をすること
    • AWSにおけるインシデントレスポンスは各種アラート等から検知して、ログ等を見て事象を確認、設定変更や環境隔離、IAMの削除等を行っていく
  • 発見的統制の第一歩: GuardDuty
    • • GuardDutyはAWS上で起こるあらゆる脅威を検知してくれる
      • まずはこのアラートから対応する体制を作る
      • 詳細は下記解説動画でも紹介しています(再掲)
  • より進んだ発見的統制
    • リクルートテクノロジーズ様の例は一つの参考になる
  • 初めやすいコンプライアンス: CIS Benchmark
    • CISはLinuxやApache等様々なセキュリティ基準を作成している団体
    • CIS AWS Foundations BenchmarkとしてAWSのセキュリティチェックの具体的な項目を定義している
    • Security Hubでチェック可能
  • より幅広いクラウドとコンプライアンス対応のDome9
    • 対応コンプライアンス
      • HIPAA
      • PCI DSS
      • GDPR
      • CIS Foundations Benchmark
      • NIST 800-53
      • FedRAMP
      • ISO 27001
      • FISC
      • などなど
    • 詳しくはこちら

全体まとめ

• 前説
  • クラウドジャーニーに合わせてセキュリティ対策
  • ゲートからガードレールへ
• 1. AWSのセキュリティと全体像
  • セキュリティはビジネスを加速する
  • 単体システムと組織的なセキュリティがある
• 2. AWSセキュリティの実践
  • CCoEやガードレールなど仕組みづくりをする
  • GuardDutyから実践的な対応を始めてみる

伝えたいメッセージ

攻めのセキュリティを実践していこう

質問回答

ウェビナーの際に頂いた質問とその回答を掲載します！

EC2ログイン用の秘密鍵はどのように管理するのが望ましいでしょうか。一般的な管理方法などございましたらご教示お願いいたします。

色んな要素がありますが、まず作成するシステムと環境毎に作成しわけていただくといいです。

管理者が複数人いる場合には鍵を共有してもいいですが、目的はコンソールへのアクセスなのでSSHの鍵を利用せずに、Systems Managerのセッションマネージャという機能をご利用いただくと、IAMユーザー毎に細かい制御を適用できたり、コマンド実行履歴を管理できたりしますのでよりおすすめです。

well-architectedの使い方ですが、社内で構築する際の指標として使用するイメージでしょうか。

Well-Architedtedフレームワークは設計原則やベストプラクティス集で、最初の設計の段階から構築後のレビューまで幅広くご活用できます。

具体的な項目ではなく指針のような形になりますので、最初(設計段階)から目を通していただくといいと思います。

こちらを見ていただくと理解が早くなると思います。

ネットワークACLを全てオープンにしてセキュリティグループだけでIPアドレス範囲やポートを制限する場合、何が問題となりえるのでしょうか？ ネットワークACLとセキュリティグループの使い分け方が分かっておらず、質問させていただきました。ご教示お願いいたします。

ネットワークACLはサブネット単位でのアクセス制御、セキュリティグループはインスタンス(ENI)単位で制御が可能でこちらのほうがより細かい機能ですので、NACLは広く、セキュリティグループは細かく絞るのが好ましいです。

よく分かる解説はこちら

（自分は未受験の）AWS認定のセキュリティスペシャリティ資格は浅く広い（実業務で使うには深さが足りない）イメージですが、合っていますか。その場合、どうやって知識を深めていくがのお勧めですか。

AWS認定は基礎、アソシエイト、プロフェッショナル、スペシャルティとありまして、スペシャルティは専門的に尖った認定になっています。

私の感触としてはセキュリティスペシャルティは十分に深く、例えば鍵管理の仕組みについて精通している必要があるなど高度なセキュリティ要件の環境で求められる知識も含んでいます。

AWSセキュリティの知識を深めていくにあたっては、結局AWS自体の幅広い知識が必要になってきますので、1つのAWS上に構築されるシステムのセキュリティ設計や実装だけでなく、全体のアーキテクトや運用の設計などを一通りこなしていくことが結果的に全般的なセキュリティを理解する近道になると思います。

経験数の代わりにするのであればこちらのラーニングパスにあるようなトレーニングを受けるのもいいと思います。

Aamazon Inspectorの利用方法について簡単にご説明頂ければと思います。

InspectorはEC2の内部に含まれるOSミドルウェアの脆弱性をプラットフォーム診断できるサービスです。

EC2に事前に適当なタグを付けておき、Inspectorのコンソールからそれを対象とした評価の設定を行って実行することで、1時間位で脆弱性の一覧が出てきます。

1回0.30USDからの非常に安い料金(東京リージョンでのホスト評価の場合、詳細は料金表)なので脆弱性診断を手始めに行いたい場合におすすめです。

ただ資料内でも説明していますが、Webアプリケーションの診断ができないことと、脆弱性の管理は弱いのでそのあたりが必要になってきたら他のツールを検討いただくといいです。

セキュリティを運用していくには専用のチームが必要そうですね。他社事例などでも構いませんが、どの程度の人数でやられているか知りたいです

組織やビジネスの規模によって全然違いますが、CCoE等で設計・開発・運用などクラウドを活用していく上で様々な役割の方々が必要になりますので2,3人ということはなく、10人程度は所属されていることが多いかと思います。

資料P99でのAZ障害やリージョンレベル障害での対応はどのような考えがあればご教授ください。

極端に言うと、AZ障害やリージョンレベルの障害でシステムが機能しなくてもいいこともあると思います。

AWSは柔軟性があるため例えばAZ障害が起きていることを確認した後、別AZにCloudFormationで環境を展開し、RDSのスナップショットからデータを復旧するのが1時間くらいでできればOK、という考え方もできると思います。

あるいは諦めてAWS側で復旧することも一つの選択肢です。

基本的にはRPO(目標復旧時点)とRTO(目標復旧時間)をシステムのグレードに合わせて作成し、どこまでやったほうがいいかを考えていけばいいです。